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PAYMENT METHOD AND SYSTEM FOR ONLINE COMMERCE 
BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates to conducting commerce utilizing the Internet, 
and more particularly to a payment system that utilizes a transaction administration 
system to process, authorize and match purchase requests to merchants, verify 
merchant fulfillment of the purchase request and execute the associated credit or debit 
payment from the purchasing party's account to the merchant. 
Description nf Related Art 

The significant increase in Internet access and use has resulted in a new 
method of conducting business - electronic commerce. In a typical electronic 
commerce transaction, a buyer purchases goods or services from a merchant that has 
established a way for prospective customers to access, order, receive or pay for that 
merchant's goods and services utilizing the Internet. These transactions are currently 
performed using conventional credit cards, debit cards, money orders or cash-on- 
1 5 delivery services of shipping companies. 

Credit cards and debit cards have been used in commerce for many years. In a 
typical conventional credit card transaction, the consumer physically authenticates 
himself in the presence of the merchant by presenting his card and agrees to the terms 
of the transaction by signing a purchase slip and simultaneously taking physical 
possession of the purchased goods. The merchant can usually electronically confirm 
that the purchase amount is within the card's credit limit. 

After the transaction, the merchant delivers the purchase slip to his bank (the 
"Acquiring Bank") for payment. Using an association, such as Visa or MasterCard, 
the Acquiring Bank delivers the purchase slip to the bank that issued the credit card 
25 (the "Issuing Bank"), which credits the Acquiring Bank. The purchase slip may be 
delivered physically or electronically. 

The Issuing Bank typically uses the ground mail system to deliver statements, 
confirm transactions, and receive payments from cardholders. 

Credit and debit cards are currently being used in Internet sales transactions as 
a form of payment. However, in an online transaction, the customer cannot physically 
present the card, sign a purchase slip, and take delivery of the goods. Credit and debit 
cards lose many of their key attributes of providing expedient, reliable and secure 

1 



20 



30 



WO 01/35570 



PCT/US00/30427 



payments. As a result of this inability, issuing banks and card associations impose 
onerous fees and expensive charge back obligations on the merchant. These expose 
the merchant to fraud by cardholders and thiefs who obtain possession of the card 
account nubers. 

5 Additionally, because of the risk of identity theft, the uncertainty surrounding 

the fulfillment of a transaction, and general privacy concerns, many users are reluctant 
to transmit account information over the Internet. 

Furthermore, for micropayment transactions, where the transaction amount is 
small, it may not be financially practical for a seller to use a conventional card as a 
1 0 method of payment for the transaction. 

The Internet also represents a significant and growing source of merchant 
fraud against the existing credit and debit card system, in part because of the rapid 
formation of merchants with a limited operating history. One of the advantages of 
Internet commerce is that the Internet is capable of connecting customers and 
15 merchants, or even two private individuals, in transactions where the parties do not 
know each other and will have no association in the future. However, these 
anonymous transactions create new types of transaction risks for all parties to an 
electronic transaction. The risks created by these anonymous transactions cannot be 
addressed with the existing debit or credit card systems. 
20 Another risk that is unique to the Internet is with the intellectual property that 

is acquired and delivered via the Internet, such as software, games or music files. 
Such intellectual property is exposed to effectively unlimited copying and use in 
violation of the rights of the owner of the intellectual property. The current payment 
systems have no reliable method or procedure that can link the purchaser of 
25 intellectual property with the use of said intellectual property, or even a method 

verifying that the purchaser in fact received a working copy of the subject intellectual 
property. Because the owner or licensor of intellectual property may have difficulty 
verifying that the purchaser received the purchased or licensed intellectual property, 
the owner is currently limited in his ability to enforce payment by the purchaser and to 
30 protect from outright theft. 

Another security issue is the potential for credit card and debit card fraud. 
Unlike a physical transaction, the merchant cannot ask the buyer for identification in 
an online transaction. Anyone that acquires a valid credit card account number can 
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potentially use it to make purchases. There is also a potential for merchant fraud. 
Once the merchant has the credit card account number, he can potentially misuse it by 
overcharging the buyer, not delivering the goods ordered after receiving payment, or 
giving the account number to another. Additionally, there is the risk of interception 
5 by third parties, as the credit or debit card account number and other personal 
information is electronically transmitted during the transaction processing. 

The current response to such issues is to use electronic certificates and 
encryption. However, such methods generally only address the card holder side of the 
security issue, and may have limited effectiveness due to technical constraints. More 
10 importantly, encryption only helps ensure that the message was not altered - it does 
not authenticate the sender of the message, nor does it ensure the accuracy of the 
original message. 

Another problem that arises with the current payment system is the difficulty 
and expense of "unwinding" a transaction. When a customer returns a purchased 
15 item, the return transaction is usually handled as a separate transaction from the 

original purchase transaction. This additional processing, which is usually manual, is 
very expensive, especially for small purchases. In some cases, it may cost a merchant 
more to process a merchandise return than the merchandise itself is worth. 

Therefore there is a need for an expedient, secure, and reliable method of 
20 conducting commerce utilizing the Internet. 

SUMMARY OF THE INVENTION 
The present invention has been made in view of the above circumstances and 
solves the problems of current payment systems by creating an on-line payment 
system that verifies the authenticity of the transaction parties, verifies that the 
25 transaction details are correct, facilitates the verification of delivery of the goods and 
services, provides increased protection to owners of intellectual property conducting 
business on the Internet, prevents the misappropriation of personal information, 
prevents Internet identity theft through credit or debit card information, and reduces 
the cost of unwinding an electronic commerce transaction in a manner that does not 
30 constrain or diminish the cost-reducing impact of the Internet on commerce. 

One object of the present invention is to provide an on-line payment system 
that uses electronic real-time connections to match, authenticate, and confirm all the 
components of a transaction between all the parties involved in the transaction that 



WO 01/35570 PCT/US00/30427 



does not require the use of traditional physical credit or debit cards or the transmission 
of card account numbers to make purchases. 

Another object of the present invention is to provide a transaction 
administration system for confirming and authorizing transactions by receiving the 

5 terms of the transaction from a first transaction party, receiving the terms of the 

transaction from a second transaction party and comparing the terms of the transaction 
received from the first transaction party with the terms of the transaction received 
from the second transaction party to determine whether the terms match. 

A further object of the present invention is to provide a method for merchants 

10 to obtain authorization of an electronic transaction by providing transaction 

information to the buyer, receiving a transaction key from the buyer, transmitting the 
transaction key to the transaction administrator and receiving a purchase authorization 
from the transaction administrator. 

A further object of the present invention is to provide a transaction 

1 5 administration system for confirming delivery of purchases by receiving the terms of 
the delivery from a transaction party, receiving the confirmation of the delivery from a 
delivery agent and comparing the terms of the delivery received from the transaction 
party with the delivery confirmation to determine whether the terms match. 

A further object of the invention is to provide a method of identifying a 

20 transaction party through his client software. 

Additional objects and advantages of the invention will be set forth in part in 
the description that follows, and in part will be obvious from the description, or may 
be learned by practice of the invention. The objects and advantages of the invention 
will be realized and attained by means of the elements and combinations particularly 

25 pointed out in the appended claims. 

To achieve these and other objects, and in accordance with the purposes of the 
invention, as embodied and broadly described herein, one aspect of the invention 
includes a method of authenticating an electronic transaction between a plurality of 
transaction parties by a transaction administrator. This method comprises receiving 

30 the terms of the transaction from a first transaction party; receiving the terms of the 
transaction from a second transaction party; comparing the terms of the transaction 
received from the first transaction party with the terms of the transaction received 
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from the second transaction party to determine whether the terms match; and if the 
terms match, validating the transaction. 

A further aspect of the invention includes a method for a seller to obtain 
authorization of an electronic transaction. This method comprises providing 
5 transaction information including a seller identifier to a buyer; receiving a transaction 
key from the buyer; transmitting the transaction key to a transaction administrator; 
and receiving an authorization from the transaction administrator. 

Another aspect of the invention includes a method of authorizing an electronic 
transaction between a plurality of transaction participants by a transaction 
10 administrator. This method comprises providing transaction information by a first 
transaction party to the transaction administrator; generating a transaction key by the 
transaction administrator and providing the transaction key from the transaction 
administrator to the first transaction party; providing the transaction key from the first 
transaction party to a second transaction party; providing the transaction key from a 
15 second transaction party to the transaction administrator for validation; and validating 
the transaction by the transaction administrator. 

Another aspect of the invention includes a method of authorizing an electronic 
transaction between a plurality of transaction participants by a transaction 
administrator. This method comprises providing transaction information by a first 
20 transaction party to the transaction administrator; generating a transaction key by the 
transaction administrator and providing the transaction key from the transaction 
administrator to the first transaction party; providing the transaction key from the first 
transaction party to a second transaction party; providing the transaction key from a 
second transaction party to the first transaction party; providing the transaction key 
25 from the first transaction party to the transaction administrator for validation; and 
validating the transaction by the transaction administrator. 

Another aspect of the invention includes a method of authenticating the 
delivery of goods between a plurality of transaction parties. This method comprises 
providing a transaction administration system for confirming delivery of purchases; 
30 receiving the terms of the delivery from a transaction party; receiving the 

confirmation of the delivery from a delivery agent; and comparing the terms of the 
delivery received from the transaction party with the delivery confirmation to 
determine whether the terms match. 
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Another aspect of the invention includes a method of authenticating a 
transaction between a plurality of transaction parties. This method comprises 
requesting a transaction from a second transaction party by a first transaction party; 
providing transaction information to the transaction administrator by the second 

5 transaction party; requesting the first transaction party to confirm the transaction 
request; providing confirmation to the transaction administrator by the first 
transaction party; comparing the confirmation with stored confirmation data for the 
first transaction party; and validating the transaction by the transaction administrator. 
Another aspect of the invention includes a method of authenticating a 

10 transaction between a plurality of transaction parties. This method comprises 

requesting a transaction by a first transaction party from a second transaction party; 
providing transaction information to the transaction administrator from the second 
transaction party; providing a transaction number to the second transaction party by 
the transaction administrator; communicating the transaction number to the first 

1 5 transaction party by the second transaction party; confirming the transaction by the 
first transaction party contacting the transaction administrator and communicating the 
transaction number; comparing the confirmation provided by the first transaction 
party with the stored transaction number; and validating the transaction by the 
transaction administrator. 

20 Another aspect of the present invention includes a method of unwinding a 

transaction between a buyer and a seller each having an account with a transaction 
administrator. This method comprises requesting a return transaction from the seller; 
receiving a return transaction number; returning goods to a delivery agent; delivering 
the return goods to the seller by the delivery agent; and crediting the buyer's account 

25 and debiting the merchant's account by the transaction administrator upon the seller's 
receipt of the return goods. 

Another aspect of the present invention includes a method of verifying the 
electronic purchase and delivery of intellectual property between a plurality of 
transaction parties, where a first transaction party requests to purchase downloadable 

30 intellectual property from a second transaction party by a transaction administrator. 
This method comprises providing transaction information to a transaction 
administrator; generating and providing a transaction key and a private delivery key to 
the first transaction party by the transaction administrator; providing the transaction 
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key to the second transaction party from the first transaction party; providing the 
transaction key to the transaction administrator by the second transaction party; 
validating the transaction by comparing the received transaction key with the one 
generated; if the transaction is validated, providing a public delivery key to the second 
5 transaction party; providing the intellectual property to the first transaction party 
encrypted with the private delivery key; and decrypting the intellectual property by 
the first transaction party. 

It is to be understood that both the foregoing general description and the 
following detailed description are exemplary and explanatory only and are not 
1 0 restrictive of the invention, as claimed. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The accompanying drawings, which are incorporated in and constitute a part 
of this specification, illustrate several embodiments of the invention that together with 
the description serve to explain the principles of the invention. 
15 In the drawings: 

Fig. 1 illustrates the enrollment process for buyers, merchants, shipping 
agents, and issuing banks. 

Fig. 2 illustrates the relationships of the transaction parties for a typical 
transaction in the present invention. 
20 Fig. 3 illustrates software components of the system of the present invention. 

Fig. 4 illustrates the connectivity of the system of the present invention. 
Fig. 5 is a flowchart illustrating the basic transaction authentication process of 
the system of the present invention. 

Fig. 6A-B illustrate embodiments of the transaction authentication process. 
25 Fig. 7A-B illustrate the data flow for embodiments of the transaction 

authentication process. 

Fig. 8 is a flowchart illustrating the process for authentication from a remote 
terminal. 

Fig. 9 is a flowchart illustrating the process for an off-line transaction from a 
30 telephone. 

Fig. 10 illustrates the Order Delivery Confirmation Service process. 
Fig. 1 1 illustrates the Online Delivery process. 
Fig. 12 illustrates the periodic payment process. 
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DETAILED DESCRIPTION 

Reference will now be made in detail to exemplary embodiments of the 
present invention, examples of which are illustrated in the accompanying drawings. 
Wherever possible, the same reference numbers will be used throughout the drawings 
5 to refer to the same or like components. 

A key issue for the growth of electronic commerce over the Internet is the 
ability to be able to order goods and services without the fear of privacy invasion or 
credit or debit card fraud. A number of encryption methods and other methods have 
been used to address this issue; however, these methods only reduce certain risks. 
10 Moreover, they do not attempt to address authentication or original message validity. 
Therefore electronic transactions are still vulnerable to theft or fraud. 

The present invention solves the problems of conventional card based 
electronic commerce transactions by creating an on-line payment system that does not 
use traditional physical credit or debit cards, signatures, or account numbers. The 
15 system of the present invention is implemented through client software on the 

computers of the system participants and a central transaction administration system. 
Each client software component interacts with the client software of one or more other 
system participants and with the central transaction administration system. The 
transaction administration system receives transaction requests other parties to a 
20 transaction and simultaneously compares the information received from each other to 
ensure that the transaction information received from each party matches, thereby 
authenticating the transaction. 

Preferably, in a typical transaction handled by the system of the present 
invention, the first party to the transaction is a buyer, the second party to the 
25 transaction is a merchant, and the transaction request is a request from the buyer to 
purchase goods or services from the merchant charging the purchase price to the 
buyer's account with a financial institution affiliated with the transaction 
administration system. The transaction administration system compares the terms of 
the transaction as the buyer knows them to the terms of the transaction as the 
30 merchant knows them, to ensure that all terms match. The terms in a buyer-merchant 
transaction may include the buyer's identity, the merchant's identity, item identifiers, 
prices and quantities, payment mechanisms, and delivery instructions. If the terms of 
the transaction as known by the buyer match the terms as known by the merchant, 

8 
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then the transaction administration system may authenticate the transaction. When the 
merchant receives authorization from the transaction administration system, he ships 
or downloads the purchased goods or information to the buyer. 

Every transaction party that participates in the system has a unique and private 
5 identifier. The identifier is assigned to a party through his client software. The actual 
party to a transaction does not even need to know what his identifier is, as the client 
software on his computer automatically identifies that party to the system. The 
identifiers are preferably embedded in the client software, and not made known to the 
users. The identifiers are used by the transaction administrator in the authentication 
10 matching process. Only the transaction administration system can tell who a party is 
through an identifier. Because a system identifier cannot be altered, duplicated or 
stolen, the risk of fraud is virtually eliminated. Additional security can be achieved by 
using a password or PIN in conjunction with the private identifier. 

In a preferred embodiment, when a buyer makes a purchase request, the client 
15 software on his computer sends his unique identifier to the client software on the 
merchant's system. The buyer's identifier becomes one of the transaction terms that 
the merchant "knows" for purposes of the authentication matching that takes place 
later. The merchant does not actually know who the buyer is, but rather the client 
software on the merchant's system receives the buyer's identifier as part of the 
20 process. The client software on the merchant's system sends the merchant's unique 
identifier to the buyer, adding to the terms of the transaction that the buyer "knows" 
through the buyer's client software. 

When the transaction administration system compares transaction terms, the 
purchase will only be approved if all of the terms, including the party identifiers, 
25 match. If all of the terms match, the transaction administration system generates and 
returns a transaction key to the buyer. To complete the process, the buyer transmits 
the transaction key to the merchant. The merchant gets final approval for the purchase 
by transmitting the transaction key back to the transaction administration system. The 
transaction administration system validates the transaction by matching the 
30 transaction key that was sent back by the merchant with the one that it generated when 
it performed the first match. The merchant does not ship or download the purchased 
goods, or perform the purchased services, until he receives a validation confirmation 
from the transaction administration system. 
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By going through this process, there is a high level of assurance that the buyer 
is buying said goods or services, and that the merchant has agreed to the terms. The 
process of matching ensures that there is no transaction misunderstanding and 
therefore little possibility of transaction fraud. 
5 Matching can be applied to the delivery of the goods or services as well as the 

sale of the goods or services. By electronically connecting the delivery agent, the 
transaction administrator can confirm actual delivery of goods and services. 

By using an electronic matching network, the system of the present invention 
allows all users, includes individuals, to act as buyers and sellers. Since both parties 
1 0 are electronically linked to a network, either can act as buyer or seller. This enables 
individuals to act as sellers, allowing for person to person electronic commerce. 

In the system of the present invention, a credit or debit card account number is 
not required. Instead, the transaction parties are directly linked with the transaction 
administration system. The accounts are established when the buyer and merchant 
15 register or enroll with the transaction administration system. The system identifies the 
transaction parties through the client software on each party's computer. 

Although the system of the present invention is described in terms of credit or 
debit cards, it should be understood that the concepts of the system of the present 
invention can be variously and appropriately applied and combined with many types 
20 of financial services and products. For example, Demand Deposit Accounts, Direct 
Debit Accounts, Lines of Credit, Securities Accounts, Mutual Fund Accounts, and 
Stored Value Accounts can be advantageously combined with or compliment the 
system of the present invention. Many types of financial transactions, such as 
installment loans, secured debt accounts or revolving debt accounts, can be 
25 implemented by the system of the present invention. 

The system of the present invention implements a Transaction Administration 
system to process purchase requests over a public network, such as the Internet. A 
Transaction Administrator (TA), working with affiliated financial institutions, may act 
as a clearinghouse, cash recipient, and/or payment disburser to the actual parties of an 
30 online transaction. The TA validates the transaction by comparing the terms of the 
transaction that one transaction party knows with the terms of the transaction that 
another transaction party knows. Parties to the transaction may include buyers, 
merchants and shipping agents. The transaction term matching that the TA performs 

10 



WO 01/35570 



PCTYUS00/30427 



can apply to sales as well as delivery transactions. The TA will validate the 

transaction only if all the terms match. 

The matching process virtually eliminates transaction and settlement risks. 

Neither party can claim to have not entered into the transaction, nor that delivery was 
5 not completed. Additionally, the terms of sale and delivery are unambiguously settled 

by the TA, thereby defining the contract between the parties. 

In the system of the present invention, the parties to an electronic transaction 

register or enroll with the system before any transactions take place. The enrollment 

process identifies a party to the system, and provides each party with the appropriate 
10 software to enable that party to participate in the system. Fig. 1 A-1D illustrate the 

preferred four types of parties to the system and the process of enrolling for each 

party. 

A preferred "Merchant" is an organization selling goods or services via the 
Internet. For a merchant to participate in the system of the present invention, he must 

15 become an Authorized Merchant with the system. As shown at step 110 in Fig. 1A, 
an online merchant can request to participate in the system, or be asked to participate 
in the system. If the merchant decides to participate, he signs an agreement with the 
TA agreeing to use the system as a form of payment. The agreement defines the 
transaction terms for the merchant, comparable to the merchant who accepts VISA or 

20 MasterCard. The TA provides the Authorized Merchant with Merchant software in 
step 112. This Merchant software may include Application Program Interfaces (APIs) 
and Applications that the Authorized Merchant must integrate into its Website and 
order fulfillment system in order to participate in the system, at step 114. The APIs 
typically manage communications with the TA and with existing Merchant software 

25 programs. The Merchant software can be electronically transmitted to the Merchant, 
or it can be delivered via CD-ROM or the like. The Merchant software preferably 
establishes a unique identifier to identify the Merchant's system to the TA at step 116. 
This Merchant ID is used throughout the system to identify the Merchant to the TA. 
A preferred "Issuing Bank" is a financial institution subject to federal and/or 

30 state banking laws that is authorized to offer consumer credit and demand deposit 
accounts in the jurisdictions in which it operates. Any Issuing Bank that participates 
in the system already has the infrastructure and technology to offer debit and credit 
transaction in real-time. 

11 
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As shown at step 120 in Fig. IB, a financial institution can request to 
participate in the system, or be asked to participate in the system. If the financial 
Institution decides to participate, it may sign a "franchise" agreement with the TA. 
The TA preferably provides Issuing Bank software to the financial institution in step 

5 122. This Issuing Bank software may include Application Program Interfaces (APIs) 
and Web Connection Modules that the financial institution integrates into its systems, 
at step 124. This software can be electronically transmitted to the financial institution, 
or it can be delivered via CD-ROM or the like. Once the software is integrated, the 
financial institution becomes an Issuing Bank within the system. 

1 0 A preferred "Shipping Agent" can be any type of shipping company or service. 

For a shipping agent to participate in the system of the present invention, he must 
become an "Participating Shipper". A Participating Shipper will utilize the system's 
tracking software and collect required signatures from package recipients as part of 
the Order Delivery Confirmation service. As shown at step 130 in Fig. 1C, a shipping 

1 5 agent can request to participate in the system, or be asked to participate in the system. 
If the shipping agent decides to participate, he signs an agreement with the TA. The 
TA provides Shipper software to the shipping agent in step 132. This Shipper 
software may include APIs and Applications that the shipping agent integrates into its 
system in order to participate in the system, at step 134. This software can be 

20 electronically transmitted to the shipping agent, or it can be delivered via CD-ROM or 
the like. Once the shipping agent has integrated the Shipper software, he becomes a 
Participating Shipper. 

A preferred "Account Holder" can be an individual or corporation that 
establishes a credit/debit relationship with an Issuing Bank. An Account Holder can 

25 set up subaccounts to manage the transactions of employees or family members. The 
subaccounts can be linked to purchase order systems or secure email approval notices 
to an authorizing party. 

To become an Account Holder in the preferred system of the present 
invention, a person or organization must request to participate in the system, as shown 

30 at step 140 in Fig. ID. When the Account Holder decides to participate, he signs an 
agreement with the TA agreeing to terms of usage. The TA provides Account Holder 
software to the Account Holder in step 142. The Account Holder software typically 
includes Internet browser plug-ins or applets. The Account Holder installs the 

12 
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Account Holder software at step 144. This software can be electronically transmitted 
to the Account Holder, or it can be delivered via CD-ROM or the like. 

The Account Holder software creates a unique identifier to identify the 
Account Holder's computer to the TA at step 146. It is through the Account Holder 
5 software that the system identifies the Account Holder. There are a number of 
methods that can be used to uniquely identify the computer or device through the 
Account Holder client software. The identifier may be determined through a fixed 
spot on the computer's hard drive, through the CPU's identifier, or through a secret 
token embedded in the software, for example. The Account Holder does not know his 
10 identifier, and cannot give it away. The transaction administration system may 
periodically establish new Account Holder identifiers to further ensure security. 
Additional security may be achieved by using a password or Personal Identification 
Number (PIN) in conjunction with the private ID established by the Account Holder 
client software. 

15 The Account Holder software is typically a browser plug-in that works with 

publicly available Internet browsers, such as Netscape Navigator and Microsoft 
Explorer. In addition, instead of a browser plug-in, the Account Holder software may 
be a Wireless Application Protocol designed to work with the Operating Systems on 
handheld wireless devices, such as Palm OS, Go OS, and Mac OS, or with digital 

20 wireless telephones. 

The Account Holder client software may have built-in links to Quicken and 
Microsoft Money, so that transaction information can be populated into these 
applications. With the Account Holder client software, the Account Holder may 
review online payment histories, and the like. 

25 The Account Holder client software may also be customized so that it can 

block purchases by amount, type of goods, or Merchant. This is an important feature 
for Account Holders who wish set up subaccounts for family members or employees. 

A preferred relationship between the participating entities of the present 
invention are shown in Fig. 2 and will now be explained. Merchant 290 is an 

30 organization selling goods or services via the Internet that has registered with the 
Transaction Administrator (TA) 250 to become an Authorized Merchant. To 
participate in the system, Merchant 290 has integrated the Merchant Software into its 
e-commerce Website and order fulfillment system. This enables purchasers to choose 

13 
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the system of the present invention as the method of payment when making purchases 
from the Merchant's Website. Account Holder 280 preferably has a standard 
Merchant-Client relationship with Merchant 290, ordering retail products and/or 
services from Merchant 290. 
5 Each participating Merchant 290 preferably establishes an account at a 

Merchant Bank 220 that also participates in the system. Merchant Bank 220 is 
responsible for making payments to the Merchant 290 on receipt of valid credit 
events. As indicated by the dashed lines, TA 250 can also act as a Merchant Bank. 
Merchants may electronically present payment events to TA 250 or a Merchant Bank 
10 220 for payment. 

In a preferred embodiment, Merchant Bank 220 or TA 250 has an account at 
each Issuing Bank 210. Merchant Bank 220 sweeps on a regular basis to credit 
Merchant accounts, collecting payments due as directed by TA 250, or TA 250 may 
act as a Merchant Bank, and process disbursements from Issuing Bank 210 to 
15 Merchant 290. 

The preferred Account Holder arrangements, Issuing banks 210 establish 
credit/debit relationships with the system's registered Account Holders 280. Issuing 
Bank 210 establishes the account and provides funds availability to the Account 
Holder 280. Issuing Bank 210 sends statements to Account Holder 280 just like a 
20 traditional credit card or debit card issuing bank. 

TA 250 preferably maintains control of discount points, coupon distribution 
and discounts from Merchants to Account Holders. TA 250 may provide customer 
service for the software and technology for Account Holders for the Issuing Bank. 
Merchant 290 may also establish an account with Shipper 260. In the 
25 preferred embodiment, Account Holder 280 receives purchases goods via delivery 
from Shipper 260. In charge-on-delivery transactions, the Account Holder's account 
is debited upon signing/receipt of the goods. Shipper 260 transmits the required 
information to TA 250. Shipper 260 also has an account with Merchant 290. 

TA 250 provides the real-time transaction clearing utilities and acts as the cash 
30 recipient from Issuing Banks 210 and payment disburser to Merchant Bank 220, or to 
Merchant 290, if it is also acting as the Merchant Bank. 

A preferred high-level view of the software components of the system of the 
present invention is show in Fig. 3. As shown, all parties to the system may 
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communicate over the Internet tlirough their respective client software components. 
Account Holder 280 communicates through the Account Holder client software, 
typically a Netscape Navigator or Microsoft Explorer Browser plug-in 380. A 
Merchant 290 uses its own Merchant Transaction systems to communicate through 
5 the Merchant client software 390, which may consist of an Authorized Merchant 
Application and API. The Merchant client software 390 may be integrated with the 
Merchant's own sales and order fulfillment systems. Issuing bank 210 communicates 
through Issuing Bank software 310, which may include Issuing Bank Web 
Connection Module and API. Like the Merchant client software, the Issuing Bank 

10 client software is integrated into the Issuing Bank's own system. Shipper 260 

communicates through Authorized Shipping Agent client software 360, which may 
include an Authorized Shipper Application API. Finally, TA 250 communicates 
through the Account and Transaction Management Application 350. The Account 
and Transaction Management Application 350 performs all of the TA functions, such 

15 as transaction term matching, account management, order fulfillment management, 
and the like. 

Although not shown in Fig. 3, the transaction parties do not have to be 
connected to the system through their respective software components over the 
Internet, or any other public network. Other modes of communication can be 

20 considered for each of the various connections shown. 

The preferred connectivity of the system of the present invention is shown in 
Fig. 4. Account Holder connections in the system are preferably Secured Server 
Links (SSLs). As shown, connection 410 between an Account Holder and a 
Merchant, connection 420 between an Account Holder and an Issuing Bank, and 

25 connection 430 between an Account Holder and the TA are Secured Server Links. 
Connection 450 between an Issuing Bank and the TA, and connection 460 between a 
Merchant and the TA are preferably either a Virtual Private Network Connection 
(VPN) or a Secure Shell Connection (SSC). 

The basic process of the system of the present invention is shown in Fig. 5. At 

30 step 510, a first transaction party sends his transaction information to the TA. At step 
530, a second transaction party sends his transaction information to the TA. At step 
550, the TA compares these transaction information packets to determine if they are 
identical. If they match, then the TA returns a transaction authorization at step 570. 

15 
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If they do not match, a return to start may occur or termination of the process may 
occur. 

The basic process outlined in Fig. 5 can be achieved through many different 
methodologies. Two preferred embodiments are shown in Figs. 6 and 7. 
5 A first preferred embodiment of the invention is illustrated in Figs 6 A and 7A. 

A transaction process begins with the Account Holder 280. As shown in Fig. 7A, 
Account Holder 280 visits Merchant's Website 290, and makes purchase selections. 
Account Holder 280 then sends a purchase request 711 to Merchant 290 selecting the 
system of the present invention as the method of payment. For example, this can 

1 0 occur after he fills his electronic shopping cart or when he selects the Merchant's 

"Purchase Now" option. The purchase request typically contains such information as 
item Universal Price Codes (UPCs), price, and quantity. 

The client software at the Merchant's Website 290 responds to the purchase 
request by first generating a transaction identifier (ID), then transmitting this 

15 transaction ID along with the Merchant ID and transaction information 712 to the 
client software on the Account Holder's computer 280. The transaction ID is used 
throughout the process to identify this particular transaction. Because one buyer and 
one merchant may have a number of transactions over time; the transaction ID is 
needed to uniquely identify this particular transaction. 

20 After the transaction information including Transaction ID and Merchant ID is 

transmitted to the Account Holder's computer, the Account Holder client software on 
the Account Holder's computer adds the Account Holder's unique ID to the 
information and transmits all of the information 713 to the TA 250. For added 
security, the Account Holder's ID may be encrypted before it is transmitted with the 

25 rest of the transaction information. The information that is sent to TA 250 in data 

packet 713 defines the transaction as the Account Holder "knows" it. It is actually the 
client software on the Account Holder's computer that knows all of the terms of the 
transaction, not the actual Account Holder, as the user of the software never sees any 
of the identifiers used in the system. Because the Account Holder ID is only now 

30 transmitted, the Merchant is never in possession of any Account Holder information. 

Upon receiving data packet 713, TA creates and transmits an Issuing Bank 
approval request 720 to Issuing Bank 210 for the amount of the transaction. The 
client software on the Issuing Bank's system 210 uses the Account Holder's ID to 

16 
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access the Account Holder's account to determine whether to approve or reject the 
amount requested. The Issuing Bank 210 then transmits the transaction approval code 
721 to TA 250. If the Issuing Bank 210 approves the transaction, TA 250 generates 
and transmits a Transaction Key 731 along with the Transaction ID to the Account 
5 Holder's computer. 

Upon receipt of the transaction key, the client software on the Account 
Holder's computer 280 sends the Transaction key and Transaction ID to Merchant 
290 in data packet 732. In addition, the Account Holder may be prompted at this time 
for delivery method instructions. Delivery information will also be passed to the 
10 Merchant 290 in data packet 732. The client software on the Merchant's system 290 
then transmits the Transaction ID, Transaction key, and transaction information 
including delivery instructions in data packet 733 to TA 250. 

TA 250 then matches keys and associated information that was sent by the 
Merchant 290. If the information matches, then TA 250 transmits an Approval Code 
15 with the Transaction ID 770 to the Merchant 290. In addition, TA 250 transmits a 
debit notice 780 to Issuing Bank 210. Upon receipt of the debit notice, Issuing Bank 
210 debits Account Holder's account and credits TA's master account. The 
Merchant's account at the Merchant Bank or with the TA is then credited. 

Finally, Merchant 290 confirms to Account Holder 280 that the transaction is 
20 complete 790, and ships the goods. 

The process for this embodiment is shown in Fig. 6A. Step 510 from Fig. 5 is 
expanded to include substeps 611, 612, and 613. At step 611, a first transaction party 
sends a transaction request to the second transaction party. Step 611 corresponds to 
data packet 711 in Fig. 7A, where the buyer makes a purchase request from a 
25 Merchant. At step 612, the second party sends the transaction information including 
his identifier to the first party. Step 612 corresponds to data packet 712 in Fig. 7A, 
where the Merchant transmits the Merchant ID, Transaction ID, and all of the 
transaction information to the buyer. At step 613, the first party transmits all of the 
information he received from the second party, including the second party's identifier, 
30 and his private identifier to the TA. Step 613 corresponds to data packet 713 in Fig. 
7A, where the client software on the Account Holder's computer encrypts the Account 
Holder's private identifier, and sends it with the transaction information received from 
the Merchant to the TA. 

17 
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Substeps 611, 612, and 613 correspond to Step 510, where a first transaction 
party sends the transaction terms as he knows them to the TA. In this embodiment, 
the first transaction party is the buyer, who is sending all of the specific purchase 
information, the Merchant's ID, and the Account Holder's ID to the TA. The client 
5 software on the Account Holder's machine manages all of the transmittals. The 
Account Holder does not have to manually transmit all of this information, and need 
not know what the client software is doing. The Account Holder simply makes a 
purchase request from the Merchant's Website. The client software on the Account 
Holder's computer receives the information from the Merchant, encrypts the Account 

10 Holder's ID and transmits the necessary information on to the TA. 

Step 620 in Fig. 6 A corresponds to data packets 720 and 721 in Fig. 7 A. At 
step 620, the TA makes a transaction approval request from the Issuing Bank for the 
Account Holder for the amount of this specific transaction, and receives the Issuing 
Bank's approval code. If the transaction is approved, then the process in Fig. 6A 

1 5 continues to step 631 . 

Step 530 from Fig. 5 is expanded to include substeps 631, 632, and 633 in Fig. 
6A. At step 631, the TA generates and sends a Transaction Key with the Transaction 
ID to the client software on the Account Holder's computer. Step 631 corresponds to 
data packet 731 in Fig. 7A. At step 632, the first party sends the transaction key and 

20 transaction ID the second party. Step 632 corresponds to data packet 732 in Fig. 7A. 
At step 633, the second party transmits all of the information he received from the 
first party, including the transaction key to the TA. Step 633 corresponds to data 
packet 733 in Fig. 7A. 

None of the substeps 631, 632, and 633 are apparent to a user of the system. 

25 The client software on the Account Holder's and the Merchant's computers handle all 
the necessary transmissions. Substeps 631, 632, and 633 combined result in Step 530. 

At step 550, the TA compares all of the transaction information received from 
the first party in step 613 to the transaction information received from the second 
party in step 633 to ensure that every term, including party identifiers, matches. In 

30 addition, the TA compares the transaction key received from the second party at step 
633 with the transaction key it generated and sent to the first party at step 631 to 
ensure a match. Only if all of the data items match does the TA send an approval 
code to the second party at step 570. 

18 
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In the preferred embodiment, the second party cannot complete the transaction 
without the transaction key. The only way that the second party can acquire the 
transaction key is through the first party. This protects the first party from 
unauthorized purchases on his account. 
5 A second preferred embodiment of the invention is shown in Figs. 6B and 7B. 

In this embodiment, all communication to the TA is through one party. In this 
embodiment, the first party performs the same steps 611, 612, and 613, transmitting 
the transaction terms to the TA. However, the TA receives the second party's 
transaction terms through the first party instead of through the TA. 
10 As shown in Fig. 7B, a transaction process begins when Account Holder 280 

visits Merchant's Website 290, and makes purchase selections. Account Holder 280 
then sends a purchase request 71 1 to Merchant 290 selecting the system of the present 
invention as the method of payment. 

The client software at the Merchant's Website 290 responds to the purchase 
15 request by first generating a transaction identifier (ID), then transmitting this 

transaction ID along with the Merchant ID and transaction information 712 to the 
client software on the Account Holder's computer 280. 

After the transaction information including Transaction ID and Merchant ID is 
transmitted to the Account Holder's computer, the Account Holder client software on 
20 the Account Holder's computer adds the Account Holder's unique ID to the 
information and transmits all of the information 713 to the TA 250. 

Upon receiving data packet 713, TA creates and transmits an Issuing Bank 
approval request 720 to Issuing Bank 210 for the amount of the transaction. The 
Issuing Bank 210 then transmits the transaction approval code 721 to TA 250. If the 
25 Issuing Bank 210 approves the transaction, TA 250 transmits a Transaction Key 731 
along with the Transaction ID to the Account Holder's computer. 

Upon receipt of the transaction key, the client software on the Account 
Holder's computer 280 sends the Transaction key and Transaction ID to Merchant 
290 in data packet 732. In addition, the Account Holder may be prompted at this time 
30 for delivery method instructions. Delivery information will also be passed to the 
Merchant 290 in data packet 732. The client software on the Merchant's system 290 
will then re-transmit the Transaction ID, Transaction key, and transaction information 
including delivery instructions in data packet 733 back to the Account Holder 280. 
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The client software on the Account Holder's computer 280 then re-transmits this 
information in data packet 734 to TA 250. 

TA 250 then matches keys and associated information that was sent by 
Account Holder 280. If the information matches, then TA 250 transmits a 

5 Transaction Approval Code with the Transaction ID 770 to Account Holder 280. The 
client software on the Account Holder's computer 280 then re-transmits the same 
information in data packet 771 to Merchant 290. 

In addition, TA 250 transmits a debit notice 780 to Issuing Bank 210. Upon 
receipt of the debit notice, Issuing Bank 210 debits Account Holder's account and 

10 credits TA's master account. The Merchant's account at the Merchant Bank or with 
the TA is then credited. 

Finally, Merchant 290 confirms to Account Holder 280 that the transaction is 
complete 790, and ships the goods. 

The process for this embodiment is shown in Fig. 6B. Step 510 from Fig. 5 is 

15 expanded to include substeps 611, 612, and 613. At step 611, a first transaction party 
sends a transaction request to the second transaction party. Step 611 corresponds to 
data packet 71 1 in Fig. 7B, where the buyer makes a purchase request from a 
Merchant. At step 612, the second party sends the transaction information including 
his identifier to the first party. Step 612 corresponds to data packet 712 in Fig. 7B, 

20 where the Merchant transmits the Merchant ID, Transaction ID and all of the 

transaction information to the buyer. At step 613, the first party transmits all of the 
information he received from the second party, including the second party's identifier, 
and his private identifier to the TA. Step 613 corresponds to data packet 713 in Fig. 
7B, where the client software on the Account Holder's computer encrypts the Account 

25 Holder's private identifier, and sends it with the transaction information. 

After performing steps 611, 612, and 613, thereby transmitting the first party's 
transaction terms to the TA, the TA gets credit approval for the transaction at step 
620. After receiving approval for the transaction, the TA generates and sends a 
transaction key to the first party at step 631 . The first party sends the transaction key 

30 to the second party at step 632. The second party transmits the transaction key and 
transaction information back to the first party at step 635. The first party resends this 
transmission to the TA at step 636. Steps 636 and 637 correspond to data packets 736 
and 737 in Fig. 7B. 

20 
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The TA uses the information received at step 636 to compare against the 
information received at step 613 and the transaction key it generated at step 631 to 
ensure that all terms match. Only if all of the data items match does the TA send an 
approval code to the first party at step 670. The first party then retransmits the 
5 approval code to the Merchant at step 671. Steps 670 and 671 correspond to data 
packets 770 and 771 in Fig. 7B. 

In this second embodiment, the Merchant does not communicate directly with 
the TA. Instead, the Merchant transmits all of his transaction information through the 
Account Holder. The transmissions are not apparent to the user at the Account 

1 0 Holder's computer. 

In the first embodiment, the TA receives the transaction key directly from the 
second party, and in the second embodiment, the TA receives the transaction key 
indirectly through the first party. However, in both embodiments, the second party 
cannot complete the transaction without the transaction key. 

15 A feature of the system of the present invention is that an Account Holder does 

not have to use his machine or device that has the Account Holder client software 
installed. In the case where the Account Holder is using a "remote" computer or 
device that does not have the Account Holder client software installed, he may still . 
request to use his account with the system as his method of payment. 

20 The transaction process for a purchase made from a remote terminal is shown 

in Fig. 8. Steps 510 and 530 from Fig. 5 are expanded to include substeps required for 
a remote transaction. In this type of transaction, the Account Holder is using a 
computer or other electronic device that is not his "home" computer, or any computer 
that does not have the Account Holder client software installed on it. 

25 As shown in step 811, the Account Holder visits the Merchant's Website on 

this remote computer and makes a purchase request, selecting the system of the 
present invention as the method of payment. At step 813, the Merchant client 
software sends the Merchant ID and transaction information to the computer that sent 
the purchase request to the Merchant. If there is some type of communication failure, 

30 the computer will not respond. This could happen because the Account Holder is 
using a computer that does not have the client software installed, for example. 
Therefore at step 815, the client software on the Merchant system will not get a 
response, and will therefore proceed to step 817. If the Merchant client software had 
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gotten a response, then this would be a standard on-iine transaction and one of the 
methods from Fig. 6 would be used. At step 817, the Merchant client software 
switches the Webpage on the Account Holder's remote computer to a remote 
transaction screen, and transmits the same transaction information as in step 813 to the 

5 TA's remote transaction site. 

The TA connects to the Account Holder's remote server site through a SSL 
connection, and at step 831 requests the user to verify the transaction and answer or 
ask one of the security questions that the Account Holder entered when the Account 
was set up. The user verifies the transaction by correctly answering or asking security 

10 questions at step 833. 

At step 840, the TA transmits a credit approval request to the Issuing Bank for 
the Account Holder in question for the transaction amount. The Issuing Bank 
approves or disapproves the amount requested by transmitting an Issuing Bank 
approval code or disapproval code to the TA. The TA may also request the Account 

15 Holder to select one of his stored delivery address(es) or enter a new delivery address 
at this point. 

If the Account Holder verified the transaction in steps 831 and 833, then the 
terms do "match" for purposes of step 550. The TA can then send a transaction 
approval code to the Merchant along with the delivery instructions in step 871. 
20 Although not shown, the TA transmits a debit notice to the Issuing Bank. Upon 

receipt of the debit notice, the Issuing Bank debits the Account Holder's account and 
credits TA's master account. The Merchant's account at the Merchant Bank is then 
credited. 

At this point the remote transaction site switches the Account Holder back to 
25 the Merchant's site where the Merchant confirms to the Account Holder that the 

transaction is complete and will be shipped. At step 873, the TA transmits an e-mail 
to the Account Holder requesting confirmation that the Account Holder completed a 
remote transaction. Confirmation must be received from the Account Holder within 
24 hours or the transaction will be cancelled. The Account Holder may e-mail the 
30 confirmation or may call a toll-free number and answer a security question to confirm 
the transaction. 

The system of the present invention can also handle offline transactions, such 
as one initiated from a telephone call. The transaction process for a purchase made 

22 
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from a telephone is shown in Fig. 9. Steps 510 and 530 from Fig. 5 are expanded to 
include substeps preferred for this type of transaction. 

As shown in step 911, the Account Holder tells a Merchant representative that 
the system of the present invention as the method of payment. This is typically done 
5 over the telephone, although it can be done in person at a Merchant's store. After 
gathering the needed information concerning the purchase request from the customer 
(Account Holder), at step 913, the Merchant transmits the Merchant ID, Transaction 
ID, customer name, UPCs, prices, purchase amount, and delivery instructions to the 
TA. The TA generates a unique off-line transaction ID for this transaction and 

10 transmits it to the Merchant at step 920. At step 922, the Merchant phone or in-store 
representative informs the Account Holder of the off-line transaction ID and 
preferably a toll-free number to call to complete the transaction. 

At step 931, the Account Holder preferably calls the toll-free number and 
enters the off-line transaction ID. Other types of communication by the Account 

15 Holder could also be considered. The TA pulls the transaction from its database and 
reads it to the Account Holder using voice generation technology. The Account 
Holder accepts or rejects the transaction at step 933. If accepted, then the TA prompts 
the Account Holder to randomly select from the Account Holder's stored security 
questions at step 935. These questions were set up when the Account Holder enrolled 

20 in the system of the present invention. The TA may then use text to voice conversion 
technology to determine whether the security questions are answered correctly. 

As in the previously described methodologies, at step 940 the TA transmits a 
credit approval request to the Issuing Bank for the Account Holder in question for the 
transaction amount. The Issuing Bank approves or disapproves the amount requested 

25 by transmitting an Issuing Bank approval code or disapproval code to the TA. If the 
Account Holder verified the transaction in steps 933 and 935, then the terms do 
"match" for purposes of step 550. The TA can then send a transaction approval code 
to the Merchant in step 971. Although not shown, the TA transmits a debit notice to 
the Issuing Bank. Upon receipt of the debit notice, the Issuing Bank debits the 

30 Account Holder's account and credits TA's master account. The Merchant's account 
at the Merchant Bank is then credited. 

The system of the present invention can also reduce fraud through its Order 
Confirmation and Delivery Service. After the Account Holder has made his purchase 

23 
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selection and the system has validated the purchase, the Account Holder may choose 
one of his previously stored delivery address(es) or enter a new delivery address. For 
example, in the first embodiment of the present invention shown in Figs 6A and 7 A, 
this can be done as part of step 632 in data packet 732. This delivery information 
5 becomes part of the transaction information that is transmitted to the TA in step 633 
as part of data packet 733. When the TA performs the match in step 550, the delivery 
information is part of the information compared to determine whether the transaction 
is valid. 

The information flow for the Order Confirmation and Delivery process is 
10 shown in Fig. 10. After Merchant 290 sends a sale completed confirmation notice 790 
to Account Holder 280 (as shown in Figs 7A and 7B), Merchant 290 transfers 
packaged goods to Shipper 260 with delivery instructions 1010. Shipper 260 then 
delivers the Shipper's package/shipping ID to Merchant through data packet 1020. 
The Merchant then sends the transaction ID along with the shipping ID and shipping 
15 date to TA 250 as data packet 1030. 

TA 250 periodically transmits its package watch list to Shipper 260 and 
indicates which ones must have signatures and from whom such signatures must be 
obtained if it is a delivery versus payment (DVP) shipment at data packet 1040. DVP 
shipments require picture identification, or some other type of physical authentication 
20 such as a thumbprint, or other biometric data. 

Goods are delivered to Account Holder's 280 specified delivery address at 
1050. The required signature or biometric sample, if any, is obtained following 
normal retry procedures. Account Holder 280 then accepts the delivery and signs if 
required at 1055. 

25 Shipper 260 transmits Package Change Statuses to TA 250 to confirm receipt 

of the goods in data packet 1060. TA 250 transmits Transaction ID and receipt status 
upon any change in status to Merchant 290 in data packet 1070. 

If the transaction is DVP, the Merchant's account is credited upon notice that 
the goods have been delivered and the authorized signature has been obtained, and TA 

30 250 notifies Issuing Bank 21 0 to debit the Account Holder's account in data packet 
1080. 

The system can also handle the transmission and downloading of purchased 
intellectual property items, such as music, news articles, and software. This use of a 

24 
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network linking buyers, sellers and a transaction administrator allows for the secure 
sales and delivery of intellectual property data items. The linkage between the 
purchase and usage of intellectual property provides better management of these 
assets, because the purchase and delivery is managed by the same system. 
5 The downloaded intellectual property goes to the Account Holder's computer 

that already has the Account Holder client software installed on it. Therefore the 
Account holder client software can track the delivery and usage of any such purchased 
and downloaded intellectual property. This link allows merchants to have a better 
understanding of who is actually downloading their intellectual property, whether the 

10 intellectual property is copied, and how many times it is copied or played. 

In addition, financial instruments such as online mutual funds can be 
purchased and delivered through the system of the present invention. The system can 
also handle person-to-person money wires and cash advances. The system can also 
securely deliver a password for an online service to an account holder. 

15 The system provides these types of electronic file and/or password delivery 

through a combination of public and private encryption keys. The Account Holder is 
the only party that ever receives the private portion of the encryption key from the 
TA. Merchants and other third parties may receive the public portion of the 
encryption key. This combination protects the downloaded files and/or password 

20 from theft and unauthorized use. 

The information flow for the online delivery process is shown in Fig. 1 1. As 
shown, the Account Holder 280 makes a purchase request from Merchant 290 for an 
intellectual property item that is capable of electronic delivery through data packet 
1111. Merchant 290 transmits the Merchant ID, transaction ID, product 

25 description(s), price information, delivery information (including date, time and 

method) to the client software on the Account Holder's computer 280 in data packet 
1112. 

The Account Holder client software 280 transmits the information received in 
packet 1112 plus the encrypted Account Holder's private ID located on the Account 
30 Holder's system to TA 250 in data packet 1113. TA 250 transmits an Issuing Bank 
approval request to Issuing Bank 210 for the amount of the purchase in data packet 
1120. Issuing Bank 210 approves or disapproves the transaction through the 
Approval/Disapproval Code 1121. 

25 
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If the credit is approved, TA 250 transmits a transaction key, the Transaction 
ID and a private portion of the online delivery encryption key to the Account Holder's 
client software 280. Account Holder client software 280 transmits the transaction key 
and Transaction ID to Merchant 290 in data packet 1132. The private portion of the 
5 online delivery encryption key will be used to decrypt the file or information when it 
is electronically delivered. By using a private encryption key in this manner, the 
delivery of the purchased electronic goods or services is more secure. 

Merchant 290 then transmits the transaction key, Merchant ID, Transaction ID 
and transaction information to TA 250 in data packet 1133. 
10 TA 250 matches the keys and associated information regarding delivery, etc. 

and sends a transaction approval code with the Transaction ID and the public portion 
of the online delivery encryption key to Merchant 290 in data packet 1170. 

Merchant 290 may then avail itself of the option to engage in a secure 
transaction for the intellectual property or password so that the information/product 
1 5 will be encrypted using the public half of the online delivery encryption key. When 
Account Holder 280 executes an unpack command on the downloaded file or the 
downloaded file automatically executes an unpack, the program will retrieve the 
private half of the encryption key from the Account Holder's client software by using 
the Transaction ID and transaction key. This private portion of the encryption key is 
20 then used to decrypt the downloaded file/password. Additionally, the unpack can set 
flags in the Account Holder client software for tracking the delivery and usage of the 
downloaded intellectual property. 

When Account Holder client software 280 completes decrypting the delivered 
file, it sends a completion code, Transaction ID and the public portion of the online 
25 delivery encryption key to TA 250 in data packet 1174. TA 250 sends a debit notice 
to Issuing Bank 210 in data packet 1180, and Issuing Bank 210 credits the TA master 
account. The Merchant's Account at the Merchant Bank or with the TA is then 
credited on the terms in accordance with the Merchant's agreement with the system. 
The system of the present invention may also be used for periodic payments. 
30 This feature may be used in sales of monthly ISP service or for an installment loan, 
for example. The information flow for a periodic payment purchase is shown in Fig. 
12. Data packet 1132 is the same as for the embodiment shown in Fig. 11, only now 
the periodic price is included in the information rather than the total purchase price. 

26 
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For periodic payment purchases, the Merchant receives a payment every 
payment period. Fig. 12 illustrates the preferred steps that are taken each payment 
period for a purchase on a periodic basis. In data packet 1240 Merchant 290 transmits 
the transaction key, transaction ID, transaction information and periodic price to TA 
5 250. Upon receipt of data packet 1240, TA 250 matches the keys and associated 
information regarding delivery , etc. and requests Issuing Bank approval for the 
periodic payment in data packet 1242. Issuing bank 210 approves or disapproves the 
amount requested and transmits an Issuing bank approval code 1244 to TA 250. 
Issuing Bank 210 will receive and approve such a request from TA 250 once every 

10 payment period. In contrast, in a full price transaction, as shown in Fig. 1 1 , the full 
purchase price is approved only once. 

After the periodic payment is approved, Issuing Bank 210 debits the Account 
Holder's account, and credits the Merchant's account with the Merchant Bank or with 
TA in data packet 1280. 

15 An important feature of the system of the present invention is the ability to 

easily "unwind" a transaction. In current systems, the return process is handled 
manually and is therefore quite expensive. It can cost as much as $25 or $30 to 
process the return of purchased goods, because every party to the transaction, 
including the buyer, the merchant and any associated financial institutions, must 

20 manually process the return transaction. With the growth of microtransactions on the 
Internet, this cost is unacceptable. 

However, in the system of the present invention, the TA has all of the data for 
every transaction that is processed through it. In addition, every party to a transaction 
is electronically linked to the TA. Therefore, the TA can process an unwind 

25 transaction as easily as a regular purchase transaction. 

In a preferred embodiment of an unwind transaction, an Account Holder can 
return a product purchased through the system of the present invention by simply 
visiting the Merchant's Website to request a return number. The system then 
processes this new transaction by sending a request for pick-up to a Shipper 

30 participating in the system. The Account Holder gives the return goods to the 

Shipper, which is tracked by the system. The Merchant receives the return goods in 
due course. The TA clears the transaction, credits the Account Holder's account and 
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debits the Merchant's account, as it tracks the delivery of the return goods. No other 
intervention by any party is needed. 

The system of the present invention can completely unwind a transaction with 
no external communication. Because the return goods were purchased through the 
5 system, the TA already has all of the information necessary for the unwind transaction 

An unwind may be handled by the system of the present invention as a regular 
transaction, where the Account Holder is the party that is delivering goods to the 
Merchant. It can be handled like a regular transaction with the parties reversed. 

While the invention has been described in detail and with reference to specific 
10 embodiments thereof, it will be apparent to one skilled in the art that various changes 
and modifications can be made therein without departing from the spirit and scope 
thereof. It is intended that the present invention cover the modifications and 
variations of this invention provided they come within the scope of the appended 
claims and their equivalents. 
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What is claimed is: 

1 1 . A method of authenticating an electronic transaction between a plurality of 

2 transaction parties, comprising the steps of: 

3 (a) receiving the terms of the transaction from a first transaction party; 

4 (b) receiving the terms of the transaction from a second transaction party; 

5 (c) comparing the terms of the transaction received from the first transaction 

6 party with the terms of the transaction received from the second 

7 transaction party to determine whether the terms match; and 

8 (d) if the terms match, validating the transaction. 

1 2. The method of claim 1 , comprising the additional step of returning the results 

2 of the validation in step (d) to a transaction party. 

1 3. The method of claim 1 , wherein step (a) comprises electronically receiving the 

2 terms of the transaction from a first transaction party. 

1 4. The method of claim 3, wherein step (a) comprises electronically receiving the 

2 terms of the transaction from client software on a first transaction party's 

3 computer system. 

1 5. The method of claim 1 , wherein step (b) comprises electronically receiving the 

2 terms of transaction from a second transaction party. 

1 6. The method of claim 5, wherein step (b) comprises electronically receiving the 

2 terms of the transaction from client software one second transaction party's 

3 computer system. 

1 7. The method of claim 1, wherein the terms of the transaction received in step 

2 (a) includes the first transaction party's identifier and the second transaction 

3 party's identifier. 
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1 8. The method of claim 1 , wherein the terms of the transaction received in step 

2 (b) includes the first transaction party's identifier, the second transaction 

3 party's identifier and a transaction key. 

1 9. The method of claim 1 , wherein step (a) comprises the additional step of 

2 obtaining credit approval for the transaction. 

1 10. The method of claim 1, wherein step (a) comprises the additional step of 

2 generating and transmitting a transaction key to the first transaction party. 

1 11. The method of claim 1 , wherein the terms compared in step (c) comprises the 

2 first transaction party's identifier, the second transaction party's identifier and 

3 sales information. 

1 12. The method of claim 1 , wherein the first transaction party is a buyer and the 

2 second transaction party is a seller. 

1 13. The method of claim 1, wherein the identifiers are generated by client software 

2 on the computer systems of the transaction parties. 

1 14. The method of claim 1 , wherein the terms of the transaction include delivery 

2 information. 

1 15. A method for a seller to obtain authorization of an electronic transaction, 

2 comprising the steps of: 

3 (a) providing transaction information including a seller identifier to a buyer; 

4 (b) receiving a transaction key from the buyer; 

5 (c) transmitting the transaction key to a transaction administrator; and 

6 (d) receiving an authorization from the transaction administrator. 

1 16. A method of authorizing an electronic transaction between a plurality of 

2 transaction participants by a transaction administrator, comprising the steps of: 
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3 (a) providing transaction information by a first transaction party to the 

4 transaction administrator; 

5 (b) generating a transaction key by the transaction administrator and 

6 providing the transaction key from the transaction administrator to the 

7 first transaction party; 

8 (c) providing the transaction key from the first transaction party to a 

9 second transaction party; 

10 ( d ) providing the transaction key from a second transaction party to the 

1 1 transaction administrator for validation; and 

1 2 ( e ) validating the transaction by the transaction administrator. 



1 



1 7. The method of claim 1 6, comprising the additional step of providing the 



2 results of the validation in step (e) to a transaction party. 

1 18. The method of claim 16, wherein step (a) comprises the steps of: 

2 (i) a first transaction party sending a transaction request to a second transaction 

3 party; 

4 (ii) the second transaction party sending transaction information and second 

5 transaction party identifier to the first transaction party; and 

6 (iii) the first transaction party sending transaction information, second 

7 transaction party identifier and first transaction party identifier to the 

8 transaction administrator. 

1 19. The method of claim 16, wherein step (c) comprises the steps of : 

2 (i) the transaction administrator sending a transaction key to the first 

3 transaction party; 

4 (ii) the first transaction party sending the transaction key to the second 

5 transaction party; and 

6 (iii) the second transaction party sending transaction information and the 

7 transaction key to the transaction administrator. 
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1 20. The method of claim 16, wherein step (a) comprises electronically transmitting 

2 transaction information from a first transaction party to the transaction 

3 administrator. 

1 21. The method of claim 20, wherein step (a) comprises electronically transmitting 

2 transaction information from client software on the first transaction party's 

3 computer system to the transaction administrator. 

1 22. The method of claim 16, wherein the transaction information includes sales 

2 information. 

1 23. The method of claim 1 6, wherein the transaction information includes delivery 

2 information. 

1 24. The method of claim 16, wherein the transaction information in step (a) 

2 includes an identifier for each transaction party. 

1 25. The method of claim 24, wherein the identifiers are generated by client 

2 software on each transaction party's computer system. 

1 26. The method of claim 16, wherein generating a transaction key in step (b) 

2 comprises the step of matching party identifiers. 

1 27. The method of claim 16, wherein step (e) comprises the step of matching the 

2 transaction key received in step (d) with the transaction key generated in step 

3 (b). 

1 28. The method of claim 16, wherein the transaction information of step (a) 

2 includes a personal identification number, and step (e) comprises the step of 

3 matching the personal identification number from step (a) with a stored 

4 personal identification number. 
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The method of claim 16, wherein step (b) comprises the additional step of 
obtaining credit approval for the transaction. 

A method of authorizing an electronic transaction between a plurality of 
transaction participants by a transaction administrator, comprising the steps of: 

(a) providing transaction information by a first transaction party to the 
transaction administrator; 

(b) generating a transaction key by the transaction administrator and providing 
the transaction key from the transaction administrator to the first 
transaction party; 

(c) providing the transaction key from the first transaction party to a second 
transaction party; 

(d) providing the transaction key from a second transaction party to the first 
transaction party; 

(e) providing the transaction key from the first transaction party to the 
transaction administrator for validation; and 

(f) validating the transaction by the transaction administrator. 

A method of authenticating the delivery of goods between a plurality of 
transaction parties, comprising the steps of: 

(a) providing a transaction administration system for confirming delivery of 
purchases; 

(b) receiving the terms of the delivery from a transaction party; 

(c) receiving the confirmation of the delivery from a delivery agent; and 

(d) comparing the terms of the delivery received from the transaction party 
with the delivery confirmation to determine whether the terms match. 

A method of authenticating a transaction between a plurality of transaction 
parties, comprising the steps of: 

(a) requesting a transaction from a second transaction party by a first 
transaction party; 

(b) providing transaction information to the transaction administrator by 
the second transaction party; 
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7 (c) requesting the first transaction party to confirm the transaction request; 

8 (d) providing confirmation to the transaction administrator by the first 

9 transaction party; 

10 (e) comparing the confirmation with stored confirmation data for the first 

1 1 transaction party; and 

1 2 (f) validating the transaction by the transaction administrator. 

1 33. A method of authenticating a transaction between a plurality of transaction 

2 parties, comprising the steps of: 

3 (a) requesting a transaction by a first transaction party from a second 

4 transaction party; 

5 (b) providing transaction information to the transaction administrator from the 

6 second transaction party; 

7 (c) providing a transaction number to the second transaction party by the 

8 transaction administrator; 

9 (d) communicating the transaction number to the first transaction party by the 

1 0 second transaction party; 

1 1 (e) confirming the transaction by the first transaction party contacting the 

12 transaction administrator and communicating the transaction number, 

13 (0 comparing the confirmation provided by the first transaction party with the 

14 stored transaction number; and 

15 (g) validating the transaction by the transaction administrator. 

1 34. A method of unwinding a transaction between a buyer and a seller each having 

2 an account with a transaction administrator, comprising the steps of: 

3 (a) requesting a return transaction from the seller; 

4 (b) receiving a return transaction number; 

5 (c) returning goods to a delivery agent; 

6 (d) delivering the return goods to the seller by the delivery agent; and 

7 (e) crediting the buyer's account and debiting the merchant's account by the 

8 transaction administrator upon the seller's receipt of the return goods. 
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1 35. A method of verifying the electronic purchase and delivery of intellectual 

2 property between a plurality of transaction parties, where a first transaction 

3 party requests to purchase downloadable intellectual property from a second 

4 transaction party by a transaction administrator, comprising the steps of: 

5 (a) providing transaction information to a transaction administrator; 

6 (b) generating and providing a transaction key and a private delivery key to 

7 the first transaction party by the transaction administrator; 

8 (c) providing the transaction key to the second transaction party from the first 

9 transaction party; 

10 (d) providing the transaction key to the transaction administrator by the 

1 1 second transaction party; 

12 (e) validating the transaction by comparing the received transaction key with 

13 the one generated; 

14 (0 if the transaction is validated, providing a public delivery key to the second 

15 transaction party; 

16 (g) providing the intellectual property to the first transaction party encrypted 

1 7 with the private delivery key; and 

1 8 (h) decrypting the intellectual property by the first transaction party. 
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